1. Field of the Invention
The present invention relates to an information processing apparatus and a session management method. More particularly, the present invention relates to an information processing apparatus for communicating with a terminal connected via a network by using an HTTP protocol, and a session management method used in the information processing apparatus.
2. Description of the Related Art
As Web technology became more advanced recently, users can use various services via a Web page displayed on a Web browser. Communications between a Web server that provides the Web page and a client including the Web browser are generally performed by an HTTP (Hypertext Transfer Protocol)
The HTTP protocol is a session-less protocol in which communications between the Web server and the client end after an HTTP response is transmitted in response to an HTTP request. Therefore, a mechanism for keeping continuity of the session is necessary in a Web application that provides the Web page. There are several methods for keeping the continuity of the session: a method for using “cookie” function, a method for including an ID in a URL for managing the session uniquely, and a method for embedding an ID for managing the session in HTML data (Web page) and the like.
In these methods, the method for using the cookie function is realized by processes shown in FIG. 1, for example. FIG. 1 is a sequence chart for explaining the method for performing session management by using the cookie function.
The client 520 sends, to a Web server 510, an HTTP request (to be referred to as “request” hereinafter) for requesting use of a predetermined service in step S1. Then, the Web server 510 sends, to the client 520, a Web page (to be referred to as “login page” hereinafter) for the user to input a user ID and a password in step S2.
After the user name and the password are input on the login page, the client 520 sends a request to the Web server 520 to log in to the Web server 520 in step S3. Then, the Web server 510 performs user authentication and the like, and generates a session object for managing information on the session for the client 520 in step S4 (start of session), and starts processes using the session object in step S5. The Web server 510 sends an HTTP response to the client 520 in which the HTTP response includes cookie information including the session ID and the Web page for providing the predetermined service. Then, the client 520 stores the session ID included in the cookie information in step S6.
After that, since any request sent from the client includes the session ID in the cookie information (step S7), the Web server 510 can continue the session between the client and the Web server 510 by using the session object already generated (steps S8-S10).
However, the above-mentioned method using the cookie function can be used only when the cookie function is enabled in the Web browser used in the client 520. Recently, many users set the cookie function disabled from the point of view of security.
When the cookie function is set to be disabled in the Web browser, the session ID sent from the Web server as cookie information is not stored in the client 520. Therefore, any request sent from the client after that does not include any session ID. Therefore, the Web server determines that any session is not started yet for the client so that the Web server performs initial processes to start a session.
The above-mentioned case is described with reference to figures. FIG. 2 is a sequence chart for explaining a case where the cookie function is set disabled in the client.
In FIG. 2, the processes from the step S21 to step S26 are the same as those of steps S1-S6 of FIG. 1. That is, a session for the client 520 starts in step S24, and a response in which a session ID is included in cookie information is sent to the client 520 from the Web server 510.
However, in FIG. 2, since the cookie function is disabled in the client 520, the session ID is not stored in the client 520.
Therefore, any request sent from the client 520 to the Web server 510 hereinafter does not include any session ID (step S27). As a result, although the Web server 510 generates a session object for the client 520 in step S24, the Web server 510 generates a session object again in step S28. For generating a session object, it is necessary to keep a certain amount of memory area. Therefore, there is a possibility in that the Web server 510 uses up all memory areas if the Web server 510 continues to generate the session object repeatedly for the same client, so that the system down may occur.